• feat: add Stainless SDK config and misc cleanups #132
• feat: rename Error to GridError and add additionalProperties to error schemas #131
• feat: add Customer API discriminators and consolidate customer changes #130
• feat: add Quote/Transaction discriminators and remove inline examples #129
• feat: add isPlatformAccount to PaymentInstructions and remove PaymentAccountOrWalletInfo refs #128
• feat: rename accounts to data in list external accounts response #127
• feat: convert single-value enums to const for base types #126 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Greptile Overview

Greptile Summary

This PR converts single-value enums to const throughout the OpenAPI schema for improved clarity and validation, affecting 37 schema files. The conversion is semantically equivalent for discriminator fields like accountType, status, customerType, and beneficiaryType.

However, the PR also flattens LightningExternalAccountInfo from a complex allOf + oneOf structure to a simple flat object, which introduces a breaking validation change:

• Before: Required exactly one of invoice, bolt12, or lightningAddress (enforced via oneOf)
• After: All three fields are optional, allowing invalid states where zero or multiple payment methods can be set

Key changes:

• Converted enum: [VALUE] to const: VALUE for 37+ single-value enums across wallet types, error schemas, customer types, and webhooks
• Flattened LightningExternalAccountInfo schema, removing the oneOf constraint that enforced mutual exclusivity
• Updated both openapi.yaml and mintlify/openapi.yaml bundled files

Issue found:

• LightningExternalAccountInfo validation is now too permissive and will accept invalid external account configurations

Confidence Score: 1/5

• This PR introduces a breaking validation change that allows invalid Lightning account configurations
• The enum-to-const conversions are safe and improve schema clarity, but the LightningExternalAccountInfo flattening removes critical validation that previously enforced exactly one payment method. This will allow API consumers to create Lightning accounts with zero payment methods or multiple conflicting methods, causing runtime errors downstream.
• Critical attention needed for openapi/components/schemas/external_accounts/LightningExternalAccountInfo.yaml and the bundled files (openapi.yaml, mintlify/openapi.yaml) that propagate the broken validation

sequenceDiagram
    participant Dev as Developer
    participant Schema as OpenAPI Schema Files
    participant Build as Build System
    participant Validator as Schema Validator
    
    Dev->>Schema: Convert single-value enums to const
    Note over Schema: accountType: enum[LIGHTNING]<br/>→ accountType: const LIGHTNING
    
    Dev->>Schema: Flatten LightningExternalAccountInfo
    Note over Schema: Remove allOf + oneOf structure<br/>Make invoice/bolt12/lightningAddress optional
    
    Schema-->>Validator: Validate new schema
    Note over Validator: ⚠️ BREAKING CHANGE<br/>Previously: exactly one payment method required<br/>Now: zero or multiple allowed
    
    Dev->>Build: Run npm run build:openapi
    Build->>Schema: Bundle modular YAML files
    Build->>Build: Generate openapi.yaml
    Build->>Build: Copy to mintlify/openapi.yaml
    
    Build-->>Dev: Updated bundled files
    
    Note over Dev,Validator: Issue: Lightning accounts can now be<br/>created without any payment method